木工多片锯锯片怎样选择?
严查！东营交警实名曝光最新一批酒驾人员名单 120人受处罚
酒后驾驶是对自己和他人生命安全极不负责的行为，为守护大家的平安出行路，东营交警一直将酒驾作为重点打击对象，近日曝光一批饮酒、醉酒名单。
对以下驾驶人醉酒驾驶行为，依法追究刑事责任，并处吊销机动车驾驶证，且五年内不得重新申领机动车驾驶证。构成交通肇事罪的，终生禁驾。
1．卢 海，驾驶证号：3709821978****7695，2019年7月26日驾驶车牌号为桂APN221的车辆在南一路被执勤民警查获。经检验酒精含量为85.07mg/100ml，系醉酒驾驶行为。
2．徐 荣，驾驶证号：3713231982****178X，2019年8月2日驾驶车牌号为鲁E809L5的车辆在东二路被执勤民警查获。经检验酒精含量为99.19mg/100ml，系醉酒驾驶行为。
3．卢文春，驾驶证号：3715211986****5538，2019年8月2日驾驶车牌号为鲁EE992V7的车辆在东二路被执勤民警查获。经检验酒精含量为227.8mg/100ml，系醉酒驾驶行为。
4．李宪勇，驾驶证号：3725231979****6016，2019年7月28日驾驶车牌号为鲁E0M350的车辆在淮河路被执勤民警查获。经检验酒精含量为128.76mg/100ml，系醉酒驾驶行为。
5．陶亮亮，驾驶证号：3203051987****1575，2019年7月29日驾驶车牌号为鲁E00406的车辆在黄河路被执勤民警查获。经检验酒精含量为116.19mg/100ml，系醉酒驾驶行为。
6．康志强，驾驶证号：3705021988****2810，2019年8月1日驾驶车牌号为鲁E32782的车辆在黄河路被执勤民警查获。经检验酒精含量为81.81mg/100ml，系醉酒驾驶行为。
7．李 贺，身份证号：2302311990****4019，2019年8月2日驾驶无牌摩托车在苏州路被执勤民警查获。经检验酒精含量为86.11mg/100ml，系醉酒驾驶行为。
8．方建国，驾驶证号：2302291963****0736，2019年7月27日驾驶车牌号为鲁E131Y5的车辆在东四路被执勤民警查获。经检验酒精含量为101.51mg/100ml，系醉酒驾驶行为。
9．陈家颖，驾驶证号：3411811990****381X，2019年7月27日驾驶车牌号为皖MHH808的车辆在东四路被执勤民警查获。经检验酒精含量为84.93mg/100ml，系醉酒驾驶行为。
10．张亮亮，驾驶证号：3705021981****3613，2019年8月1日驾驶车牌号为鲁EE9863的车辆在广州路被执勤民警查获。经检验酒精含量为119.14mg/100ml，系醉酒驾驶行为。
11．谢清龙，驾驶证号：3705221988****171X，2019年8月1日驾驶车牌号为鲁E56622的车辆在广州路被执勤民警查获。经检验酒精含量为185.83mg/100ml，系醉酒驾驶行为。
12．刘学亮，驾驶证号：3705221988****043X，2019年7月30日驾驶车牌号为鲁E2G533的车辆在黄河路被执勤民警查获。经检验酒精含量为86.47mg/100ml，系醉酒驾驶行为。
13．李红峰，驾驶证号：3705231986****4915，2019年7月26日驾驶车牌号为鲁E7E359的车辆在广饶县辛河路被执勤民警查获。经检验酒精含量为190.45mg/100ml，系醉酒驾驶行为。
14．杨增强，驾驶证号：3705231984****4612，2017年7月26日驾驶车牌号为鲁E0B590的车辆在广饶县辛河路被执勤民警查获。经检验酒精含量为120.96mg/100ml，系醉酒驾驶行为。
15．王庆峰，驾驶证号：3705231967****4215，2019年7月27日驾驶车牌号为鲁E55080的车辆在广饶县辛河路被执勤民警查获。经检验酒精含量为112.02mg/100ml，系醉酒驾驶行为。
16．王孟村，驾驶证号：3705021965****1611，2019年7月28日驾驶车牌号为鲁E8862Q的车辆在河口区永兴路被执勤民警查获。经检验酒精含量为141.15mg/100ml，系醉酒驾驶行为。
17．王顺安，驾驶证号：3705031963****0054，2019年6月18日驾驶车牌号为鲁E2697G的车辆在河口区河口宾馆院内被执勤民警查获。经检验酒精含量为131.6mg/100ml系醉酒驾驶行为。
18．王现令，驾驶证号：3705031978****1816，2019年6月28日驾驶车牌号为鲁E175T0的车辆在河口区河民路被执勤民警查获。经检验酒精含量为141.84mg/100ml系醉酒驾驶行为。
19．许凤义，身份证号：3705211957****4030，2019年7月11日无证驾驶电动四轮电动车在垦利区黄河口镇被执勤民警查获。经检验酒精含量为183.51mg/100ml，系醉酒驾驶行为。
20．邱方喜，驾驶证号：3705021962****4012，2019年7月9日驾驶车牌号为鲁E382K3的车辆在垦利区兴隆生态林场北门处被执勤民警查获。经检验酒精含量为112.3mg/100ml，系醉酒驾驶行为。
21．韩洪亮，驾驶证号：3705211969****0033，2019年7月8日驾驶车牌号为鲁E535N7的车辆在垦利区渤海路被执勤民警查获。经检验酒精含量为178.18mg/100ml，系醉酒驾驶行为。
22．张景全，驾驶证号：3705211967****0838，2019年6月22日驾驶车牌号为鲁EU3339的车辆行驶垦利区胜兴路被执勤民警查获。经检验酒精含量为131.93mg/100ml，系醉酒驾驶行为。
23．王召江，驾驶证号：3705211968****4415，2019年6月15日驾驶车牌号为鲁E286F4的车辆在垦利区渤海路被执勤民警查获。经检验酒精含量为90.92mg/100ml，系醉酒驾驶行为。
24．王渤海，驾驶证号：3705211977****1610，2019年7月15日驾驶车牌号为鲁EKR700的车辆在垦利区北二路被执勤民警查获。经检验酒精含量为96.17mg/100ml，系醉酒驾驶行为。
25．巴新忠，驾驶证号：3705211969****2051，2019年6月28日驾驶车牌号为鲁E9T797的车辆在垦利区胜兴路被执勤民警查获。经检验酒精含量为114.3mg/100ml，系醉酒驾驶行为。
26．陈 琪，驾驶证号：3705221991****0218，2019年7月14日驾驶车牌号为鲁E765X9的车辆在垦利区德州路被执勤民警查获。经检验酒精含量为134.04mg/100ml，系醉酒驾驶行为。
27．卢庆华，驾驶证号：3708311970****515X，2019年7月2日驾驶车牌号为鲁E039Y6的车辆在垦利区井下立交桥北侧被执勤民警查获。经检验酒精含量为105.5mg/100ml，系醉酒驾驶行为。
28．曹延苓，驾驶证号：3708311986****2417，2019年8月7日驾驶车牌号为鲁E007Q7的车辆在北二路被执勤民警查获。经检验酒精含量为94.01mg/100ml，系醉酒驾驶行为。
29．李海青，驾驶证号：3706231973****2235，2019年8月1日驾驶车牌号为京MH5033的车辆在西四路被执勤民警查获。经检验酒精含量为131.29mg/100ml，系醉酒驾驶行为。
30．孔 波，驾驶证号：3708811980****5816，2019年8月2日驾驶车牌号为鲁E64359的车辆在西四路被执勤民警查获。经检验酒精含量为132.2mg/100ml，系醉酒驾驶行为。
31．宋宁海，驾驶证号：3705021982****361X，2019年8月2日驾驶车牌号为鲁EJN686的车辆在西四路被执勤民警查获。经检验酒精含量为83.25mg/100ml，系醉酒驾驶行为。
32．薄文华，驾驶证号：3705211982****0413，2019年8月4日驾驶车牌号为鲁E500CN的车辆在西四路被执勤民警查获。经检验酒精含量为168.91mg/100ml，系醉酒驾驶行为。
33．张珊珊，驾驶证号：3714021990****6127，2019年8月4日驾驶车牌号为鲁NNF692的车辆在西四路被执勤民警查获。经检验酒精含量为91.95mg/100ml，系醉酒驾驶行为。
对以下驾驶人酒后驾驶行为，处暂扣六个月机动车驾驶证，并处1000元罚款，驾驶证记12分处罚。
1．宋建德，驾驶证号：3705231975****2717，2019年8月2日驾驶车牌号为鲁E3803的车辆在东二路被执勤民警查获。经检验酒精含量为36mg/100ml，系酒后驾驶行为。
2．杨建勇，驾驶证号：3723231978****3339，2019年8月7日驾驶车牌号为鲁E0S985的车辆在东二路被执勤民警查获。经检验酒精含量为35mg/100ml，系酒后驾驶行为。
3．刘克兴，驾驶证号：3705221985****1730，2019年8月7日驾驶车牌号为鲁EW2516的车辆在东二路被执勤民警查获。经检验酒精含量为45mg/100ml，系酒后驾驶行为。
4．张连庆，驾驶证号：3714811983****6339，2019年7月26日驾驶车牌号为鲁E919Q8的车辆在东二路被执勤民警查获。经检验酒精含量为44mg/100ml，系酒后驾驶行为。
5．陈政宇，驾驶证号：3705021986****0011，2019年8月7日驾驶车牌号为鲁EL1772的车辆在黄河路被执勤民警查获。经检验酒精含量为77mg/100ml，系酒后驾驶行为。
6．郭 阳，驾驶证号：3705221997****0610，2019年8月8日驾驶车牌号为鲁E215D3的车辆在府前大街被执勤民警查获。经检验酒精含量为67mg/100ml，系酒后驾驶行为。
7．杨风选，身份证号：3723241963****1516，2019年8月8日驾驶电动四轮车在府前大街被执勤民警查获。经检验酒精含量为72mg/100ml，系酒后驾驶行为。
8．冉新宇，驾驶证号：3705021995****2411,2019年8月2日驾驶车牌号为鲁E74920的车辆在苏州路发生道路交通事故。经检验酒精含量为73.87mg/100ml，系酒后驾驶行为。
9．牛保鹏，驾驶证号：3705231982****4619，2019年7月17日驾驶车牌号为鲁E92C05的车辆在辛河路被执勤民警查获。经检验酒精含量为64.82mg/101ml，系酒后驾驶行为。
10．李来运，驾驶证号：3729261982****3938，2019年8月2日驾驶车牌号为鲁R01P11的车辆在广饶县綦公路被执勤民警查获。经检验酒精含量为34mg/100ml，系酒后驾驶行为。
11．赵延贵，驾驶证号：3705231970****3318，2019年8月7日驾驶车牌号为鲁E2C583的车辆在广饶县蔡颜路耿家村北侧被执勤民警查获。经检验酒精含量为25mg/100ml，系酒后驾驶行为。
12．宋春海，驾驶证号：3705231979****3338，2019年8月7日驾驶电动四轮车在广饶县广饶镇耿家村北被执勤民警查获。经检验酒精含量为50mg/100ml，系酒后驾驶行为。
13．李文宝，驾驶证号：3705231975****4219，2019年8月5日驾驶车牌号为鲁E1865A的车辆在广饶县乐安大街被执勤民警查获。经检验酒精含量为48mg/100ml，系酒后驾驶行为。
14．刘汝敏，驾驶证号：3707831984****2710，2019年8月2日驾驶车牌号为鲁V8E087的车辆在广饶县乐安大街孙武湖桥被执勤民警查获。经检验酒精含量为64mg/100ml，系酒后驾驶行为。
15．刘卫东，驾驶证号：3705231979****0319，2019年8月2日驾驶车牌号为鲁EV8111的车辆在广饶县乐安大街被执勤民警查获。经检验酒精含量为22mg/100ml，系酒后驾驶行为。
16．马茂才，驾驶证号：3705231983****0313，2019年8月2日驾驶车牌号为鲁E902E9的车辆在广饶县乐安大街被执勤民警查获。经检验酒精含量为52mg/100ml，系酒后驾驶行为。
17．李德成，身份证号：3705231996****2012，2019年8月5日驾驶车牌号为鲁EE3249的车辆在广饶县大王镇阳河路被执勤民警查获。经检验酒精含量为70mg/100ml，系酒后驾驶行为。
18．蒋海港，驾驶证号：3705231972****3059，2019年8月5日驾驶车牌号为鲁ETV299的车辆在广饶县大王镇阳河路被执勤民警查获。经检验酒精含量为65mg/100ml，系酒后驾驶行为。
19．孙西卿，身份证号：3705231952****4910，2019年7月12日驾驶低速电动货车在广饶县广北中心街被执勤民警查获。经检验酒精含量为76.45mg/100ml，系酒后驾驶行为。
20．李明鑫，驾驶证号：3701261998****651X，2019年8月3日驾驶车牌号为鲁A7J3U2的车辆在广饶县齐安路被执勤民警查获。经检验酒精含量为31mg/100ml，系酒后驾驶行为。
21．刘树朋，驾驶证号：3723281971****1517，2019年8月3日驾驶车牌号为云C18P88的车辆在广饶县齐安路被执勤民警查获。经检验酒精含量为70mg/100ml，系酒后驾驶行为。
22．孙希亭，驾驶证号：3705031984****0918，2019年8月4日驾驶车牌号为鲁E2195J的车辆在河口区河滨路被执勤民警查获。经检验酒精含量为20mg/100ml，系酒后驾驶行为。
23．高居祥，驾驶证号：3723251974****4495，2019年8月3日驾驶车牌号为鲁M06P19的车辆在河口区共青团路被执勤民警查获。经检验酒精含量为24mg/100ml，系酒后驾驶行为。
24．田 朗，驾驶证号：4127021972****3116，2019年8月6日驾驶车牌号为鲁E83J29的车辆在河口区共青团路被执勤民警查获。经检验酒精含量为33mg/100ml，系酒后驾驶行为。
25．曹美彪，驾驶证号：3723231982****331X，2019年8月5日驾驶车牌号为鲁G60992的车辆在河口区新盐路被执勤民警查获。经检验酒精含量为74mg/100ml，系酒后驾驶行为。
26．胡文选，驾驶证号：3715811993****3516，2019年8月1日驾驶车牌号为鲁E6Z598的车辆在河口区海盛路被执勤民警查获。经检验酒精含量为25mg/100ml，系酒后驾驶行为。
27．陈荣星，驾驶证号：3705031972****221X，2019年8月4日驾驶车牌号为鲁EAM611的车辆在河口区河聚路被执勤民警查获。经检验酒精含量为31mg/100ml，系酒后驾驶行为。
28．赵东海，驾驶证号：3707811986****4571，2019年8月5日驾驶车牌号为鲁VP208E的车辆在河口区海盛路被执勤民警查获。经检验酒精含量为34mg/100ml，系酒后驾驶行为。
29．陈玉金，驾驶证号：3705031988****063X，2019年8月5日驾驶车牌号为鲁E788AV的车辆在河口区海盛路被执勤民警查获。经检验酒精含量为26mg/100ml，系酒后驾驶行为。
30．毕玉东，驾驶证号：3705031974****2213，2019年8月6日驾驶车牌号为鲁E177K8的车辆在河口区利六路被执勤民警查获。经检验酒精含量为20mg/100ml，系酒后驾驶行为。
31．郭钊懿，驾驶证号：3705021989****6416，2019年8月4日驾驶车牌号为鲁E3912Q的车辆在开发区东四路被执勤民警查获。经检验酒精含量为54mg/100ml，系酒后驾驶行为。
32．张松松，驾驶证号：3705021990****6053，2019年8月5日驾驶车牌号为鲁E57K91的车辆在开发区东四路被执勤民警查获。经检验酒精含量为20mg/100ml，系酒后驾驶行为。
33．王翠香，驾驶证号：3723311963****3727，2019年8月6日驾驶车牌号为鲁E3A577的车辆在开发区北一路被执勤民警查获。经检验酒精含量为45mg/100ml，系酒后驾驶行为。
34．尹章信，驾驶证号：3203811984****4497，2019年8月1日驾驶车牌号为苏CW107P的车辆在开发区广州路被执勤民警查获。经检验酒精含量为33.26mg/100ml，系酒后驾驶行为。
35．岳玉文，驾驶证号：3703031970****3553，2019年7月29日驾驶车牌号为鲁E82753的车辆在垦利区郝孟路前岳村西侧100米处被执勤民警查获。经检验酒精含量为68mg/100ml，系酒后驾驶行为。
36．王明峰，驾驶证号：3705211989****1214，2019年7月28日驾驶车牌号为鲁E507H7的车辆在垦利区郝孟路前岳村西侧500米处被执勤民警查获。经检验酒精含量为77mg/100ml，系酒后驾驶行为。
37．刘耀雷，驾驶证号：3705211987****163X，2019年8月2日驾驶车牌号为鲁E0665U的车辆在垦利区杨董路被执勤民警查获。经检验酒精含量为39mg/100ml，系酒后驾驶行为。
38．李建成，驾驶证号：3705211986****1612，2019年8月4日驾驶车牌号为鲁E1720U的车辆在垦利区杨董路被执勤民警查获。经检验酒精含量为39mg/100ml，系酒后驾驶行为。
39．郭光峰，驾驶证号：3705221968****171X，2019年6月30日驾驶车牌号为鲁05-48530的车辆在垦利区228省道被执勤民警查获。经检验酒精含量为38mg/100ml，系酒后驾驶行为。
40．田兰春，驾驶证号：3705211975****001X，2019年6月14日驾驶车牌号为鲁A377V7的车辆在垦利区垦孤路被执勤民警查获。经检验酒精含量为38mg/100ml，系酒后驾驶行为。
41．隋 营，驾驶证号：3705211988****0038，2019年6月14日驾驶车牌号为鲁E286F3的车辆在垦利区渤海路被执勤民警查获。经检验酒精含量为63mg/100ml，系酒后驾驶行为。
42．吴利锋，驾驶证号：1326291970****8331，2019年6月17日驾驶蒙H6692E的车辆在垦利区永馆路被执勤民警查获。经检验酒精含量为33mg/100ml，系酒后驾驶行为。
43．王玉明，驾驶证号：3705021967****2834，2019年6月19日驾驶车牌号为鲁EVU696的车辆在垦利区博新路被执勤民警查获。经检验酒精含量为63mg/100ml，系酒后驾驶行为。
44．王新国，身份证号：3705221971****1336，2019年6月20日驾驶电动四轮车在垦利区胜兴路被执勤民警查获。经检验酒精含量为33mg/100ml，系酒后驾驶行为。
45．杜庆龙，身份证号：3708111959****5517，2019年6月21日驾驶三轮车在垦利区碧海路被执勤民警查获。经检验酒精含量为36mg/100ml，系酒后驾驶行为。
46．高 伦，驾驶证号：3705211975****201X，2019年6月24日驾驶车牌号为鲁E055M0的车辆在垦利区胜利路被执勤民警查获。经检验酒精含量为37mg/100ml，系酒后驾驶行为。
47．丁永富，身份证号：3705211963****4417，2019年6月25日驾驶摩托车在垦利区广兴路被执勤民警查获。经检验酒精含量为27mg/100ml，系酒后驾驶行为。
48．刘国福，驾驶证号：3705211978****005X，2019年6月25日驾驶车牌号为鲁E8U617的车辆在垦利区广兴路被执勤民警查获。经检验酒精含量为41mg/100ml，系酒后驾驶行为。
49．谢宝石，驾驶证号：3705211974****015X，2019年6月28日驾驶车牌号为鲁EL5552的车辆在垦利区胜兴路被执勤民警查获。经检验酒精含量为42mg/100ml，系酒后驾驶行为。
50．张永贵，驾驶证号：3705211967****1616，2019年8月4日驾驶车牌号为鲁ECN576的车辆在垦利区杨董路被执勤民警查获。经检验酒精含量为33mg/100ml，系酒后驾驶行为。
51．许金海，驾驶证号：3705211958****3610，2019年7月2日驾驶车牌号为鲁ES3929的车辆在垦利区018乡道被执勤民警查获。经检验酒精含量为64mg/100ml，系酒后驾驶行为。
52．王如发，驾驶证号：3705031966****0933，2019年7月4日驾驶车牌号为鲁E189BW的车辆在垦利区德州路被执勤民警查获。经检验酒精含量为26mg/100ml，系酒后驾驶行为。
53．裴立志，驾驶证号：4127021974****2532，2019年7月4日驾驶车牌号为鲁E018R2的车辆在垦利区胜利路被执勤民警查获。经检验酒精含量为73mg/100ml，系酒后驾驶行为。
54．王庆福，驾驶证号：3705211951****4016，2019年7月7日驾驶车牌号为鲁ED00982的车辆在垦利区博新路被执勤民警查获。经检验酒精含量为39mg/100ml，系酒后驾驶行为。
55．谭洪勇，驾驶证号：3705031976****2612，2019年7月9日驾驶车牌号为鲁E3073S的车辆在垦利区德州路被执勤民警查获。经检验酒精含量为48mg/100ml，系酒后驾驶行为。
56．李 明，驾驶证号：3705021963****441X，2019年7月14日驾驶车牌号为鲁E52L27的车辆在垦利区德州路被执勤民警查获。经检验酒精含量为29mg/100ml，系酒后驾驶行为。
57．刘福建，驾驶证号：3705211973****0019，2019年7月14日驾驶车牌号为鲁E6Q139的车辆在垦利区德州路被执勤民警查获。经检验酒精含量为29mg/100ml，系酒后驾驶行为。
58．张瑞亮，驾驶证号：3705211966****2839，2019年7月15日驾驶车牌号为鲁E1018U的车辆在垦利区博新路被执勤民警查获。经检验酒精含量为22mg/100ml，系酒后驾驶行为。
59．王仕豪，驾驶证号：3705211997****3215，2019年7月17日驾驶车牌号为鲁EY2538的车辆在垦利区博新路被执勤民警查获。经检验酒精含量为52mg/100ml，系酒后驾驶行为。
60．尚应彬，驾驶证号：3705221986****0417，2019年7月17日驾驶车牌号为鲁E21C55的车辆在垦利区广兴路被执勤民警查获。经检验酒精含量为33mg/100ml，系酒后驾驶行为。
61．张国栋，驾驶证号：3705021971****3611，2019年7月19日驾驶车牌号为鲁E5M885的车辆在垦利区广兴路被执勤民警查获。经检验酒精含量为23mg/100ml，系酒后驾驶行为。
62．胡延亮，身份证号：3705211958****0035，2019年7月19日驾驶电动四轮车在垦利区胜兴路被执勤民警查获。经检验酒精含量为21mg/100ml，系酒后驾驶行为。
63．冀永学，驾驶证号：3705211971****4038，2019年7月20日驾驶车牌号为鲁E0C629的车辆在垦利区广兴路被执勤民警查获。经检验酒精含量为78mg/100ml，系酒后驾驶行为。
64．闫拥军，驾驶证号：3705211969****4419，2019年7月23日驾驶车牌号为鲁ED06999的车辆在垦利区广兴路被执勤民警查获。经检验酒精含量为31mg/100ml，系酒后驾驶行为。
65．赵建军，驾驶证号：3705021971****1212，2019年7月24日驾驶车牌号为鲁E2316X的车辆在垦利区德州路被执勤民警查获。经检验酒精含量为45mg/100ml，系酒后驾驶行为。
66．韩吉滨，驾驶证号：3705211968****1616，2019年7月27日驾驶车牌号为鲁EKR978的车辆在垦利区广兴路被执勤民警查获。经检验酒精含量为23mg/100ml，系酒后驾驶行为。
67．于胜利，驾驶证号：3705021976****4455，2019年7月30日驾驶车牌号为鲁ELJ550的车辆在垦利区德州路被执勤民警查获。经检验酒精含量为61mg/100ml，系酒后驾驶行为。
68．彭玉恩，驾驶证号：3701211965****0039，2019年7月30日驾驶车牌号为鲁A909C7的车辆在垦利区胜兴路被执勤民警查获。经检验酒精含量为38mg/100ml，系酒后驾驶行为。
69．付 义，驾驶证号：3724021975****0311，2019年7月27日驾驶车牌号为鲁E8557R的车辆在西三路被执勤民警查获。经检验酒精含量为78.92mg/100ml，系酒后驾驶行为。
70．李玉田，驾驶证号：3728011971*****138，2019年7月29日驾驶车牌号为鲁EG8613的车辆在西四路被执勤民警查获。经检验酒精含量为69.2mg/100ml，系酒后驾驶行为。
71．张兴洲，驾驶证号：3705231991****2016，2019年7月29日驾驶车牌号为鲁E39G00的车辆在西四路被执勤民警查获。经检验酒精含量为47.47mg/100ml，系酒后驾驶行为。
72．纪校法，驾驶证号：3711221979****7613，2019年7月30日驾驶车牌号为鲁M0Z601的车辆在西三路被执勤民警查获。经检验酒精含量为79mg/100ml，系酒后驾驶行为。
73．岳新港，驾驶证号：3705021986****0015，2019年7月30日驾驶车牌号为鲁ENZ586的车辆在西三路被执勤民警查获。经检验酒精含量为61mg/100ml，系酒后驾驶行为。
74．袁鹏飞，驾驶证号：3723231996****1215，2019年7月30日驾驶车牌号为鲁M698X8的车辆在西三路被执勤民警查获。经检验酒精含量为77mg/100ml，系酒后驾驶行为。
75．付增军，驾驶证号：3705021971****1615，2019年8月1日驾驶车牌号为鲁E5K570的车辆在西三路被执勤民警查获。经检验酒精含量为49mg/100ml，系酒后驾驶行为。
76． 高卫青，驾驶证号：3705211978****3616，2019年8月1日驾驶车牌号为鲁E13406的车辆在西四路被执勤民警查获。经检验酒精含量为52.38mg/100ml，系酒后驾驶行为。
77．王增新，驾驶证号：3705021974****363X，2019年8月1日驾驶车牌号为鲁E079AJ的车辆在西四路被执勤民警查获。经检验酒精含量为73.2mg/100ml，系酒后驾驶行为。
78． 王梦坤， 驾驶证号：3705021996****0810，2019年8月1日驾驶车牌号为鲁E636X1的车辆在西三路被执勤民警查获。经检验酒精含量为53mg/100ml，系酒后驾驶行为。
79．张明宝，驾驶证号：2302231976****2019，2019年8月2日驾驶车牌号为鲁EIU558的车辆在西四路被执勤民警查获。经检验酒精含量为45mg/100ml，系酒后驾驶行为。
80．赵殿民，驾驶证号：3705221963****0911，2019年8月2日驾驶车牌号为鲁EX2985的车辆在利津县利沾路被执勤民警查获。经检验酒精含量为60mg/100ml，系酒后驾驶行为。
81．翟宪芳，驾驶证号：3705021978****2035， 2019年8月5日驾驶车牌号为鲁E9Z585的车辆在东二路被执勤民警查获。经检验酒精含量为47mg/100ml，系酒后驾驶行为。
82． 盖艳荣，驾驶证号：3705221973****0927，2019年8月5日驾驶车牌号为鲁M6762X的车辆在利津县前宋路被执勤民警查获。经检验酒精含量为45mg/100ml，系酒后驾驶行为。
83． 崔传鹏，驾驶证号：3705221990****201X，2019年8月5日驾驶车牌号为鲁EK0412的车辆在利津县利沾路被执勤民警查获。经检验酒精含量为60mg/100ml，系酒后驾驶行为。
84． 张其岷，驾驶证号：3705221968****1577，2019年8月5日驾驶车牌号为鲁EJW677的车辆在利津县前南路被执勤民警查获。经检验酒精含量为38mg/100ml，系酒后驾驶行为。
85． 赵鹏真，驾驶证号：3705221981****1434，2019年8月5日驾驶车牌号为鲁EQ1367的车辆在利津县前南路被执勤民警查获。经检验酒精含量为22mg/100ml，系酒后驾驶行为。
86． 崔金刚，驾驶证号：3705221983****1734，2019年8月3日驾驶车牌号为鲁E3715N的车辆在利津县新盐路被执勤民警查获。经检验酒精含量为35mg/100ml，系酒后驾驶行为。
87． 张乃磊，驾驶证号：3705221983****1576，2019年8月2日驾驶车牌号为鲁E937CD的车辆在利津县集付路被执勤民警查获。经检验酒精含量为49mg/100ml，系酒后驾驶行为。
宜信开源｜手把手教你安装第一个LAIN应用
拓展阅读：宜信开源|详解PaaS平台LAIN的功能和架构
宜信开源|一个实例解析PaaS平台LAIN的9大杀手级功能
一、安装 LAIN 集群
本节包含三种场景下安装LAIN集群
本地启动虚拟机安装LAIN集群，可供本地测试开发物理服务器/虚拟机安装LAIN集群云服务器安装LAIN集群三者都需要从 GitHub 获取已经发布的 LAIN 版本源代码:
下载源码后在目标机器上解压即可。
tar xf lain-VERSION.tar.gz
1、本地安装LAIN集群
1）环境依赖
Linux / MacOS能够连接到互联网VirtualBox 5.1.22 r115126 (Qt5.6.2)Vagrant 1.9.4最少 2G 剩余内存（如果需要拉起多个节点，最少 3G）2）初始化
启动并初始化第一个节点
cd lain-VERSIONvagrant up --provision
启动耗时取决于 vagrant box 下载时间, 启动完成后 vagrant 会自动 执行bootstrap进行初始化, 初始化需要至少20分钟，取决于网络速度。 初始化过程为集群默认配置vip=192.168.77.201
如果出现以下错误：
Vagrant was unable to mount VirtualBox shared folders. This is usuallybecause the filesystem "vboxsf" is not available. This filesystem ismade available via the VirtualBox Guest Additions and kernel module.Please verify that these guest additions are properly installed in theguest. This is not a bug in Vagrant and is usually caused by a faultyVagrant box. For context, the command attempted was:mount -t vboxsf -o uid=1000,gid=1000 vagrant /vagrantThe error output from the command was:/sbin/mount.vboxsf: mounting failed with the error: No such device
这个错误是因为宿主机的 Virtual Box 的 Guest Additions 与 laincloud/centos-lain box 已安装的 Guest Additions 版本不一致引起的，导致无法创建 /vagrant 这个同步 目录。请修改工程根目录下的 Vagrantfile，禁止宿主机强行安装新版本的 Guest Additions， 即添加如下配置：
config.vbguest.auto_update = false
3）添加更多节点
vagrant up node2# 待 node2 启动后[vagrant@node1 ~]$ cd /vagrant[vagrant@node1 ~]$ sudo lainctl node add -p playbooks node2:192.168.77.22# root 密码为 vagrant
4）同理可以如此添加 node3
2、物理服务器/虚拟机安装LAIN集群
1）环境依赖
CentOS 7.2NTP 服务保证节点间时间一致需要能访问到可用的 yum 源（包括 epel）能够连接到互联网各节点之间能够互相 ssh各节点 hostname 不同各个节点位于同一个路由器之内2）初始化
第一个节点
cd lain-VERSION# 选择一个同网段的未被使用的 IP 地址作为 VIPsudo ./bootstrap -r docker.io/laincloud --vip={{ vip }}
国内用户建议通过 -m 参数使用 aliyun 的加速器下载镜像，使用方式为
sudo ./bootstrap -m \-r docker.io/laincloud --vip=192.168.77.201
添加更多节点
# 需要输入 root 密码sudo lainctl node add -p playbooks {{ hostname }}:{{ ip }}
3、云服务器安装LAIN集群
1）环境依赖
CentOS 7.2NTP 服务保证节点间时间一致需要能访问到可用的 yum 源（包括 epel）能够连接到互联网各节点之间能够互相 ssh各节点 hostname 不同各个节点位于同一个 VPC （或虚拟路由器）之内3) 初始化
第一个节点
cd lain-VERSION# 如果 VPC 不对数据包进行来源 IP 限制（如青云）sudo ./bootstrap -r docker.io/laincloud# 如果 VPC 限制了数据包的来源 IP（如阿里云）sudo ./bootstrap -r docker.io/laincloud --ipip
添加更多节点
# 需要输入 root 密码sudo lainctl node add -p playbooks {{ hostname }}:{{ ip }}
4、配置LAIN Console 的域名解析
LAIN Console 组件是 LAIN 集群的控制台，配置域名解析后即可在浏览器访问
echo "IP/VIP console.lain.local" >> /etc/hosts
5、常见问题
add-node ssh-copy-id 失败
如果出现 ssh-copy-id 失败，可能需要把 node1:/root/.ssh/lain.pub 内容放到 node2:/root/.ssh/authorized_keys里，新增一行。当然原因可能是多样的，最有可能就是 lain-02 的 /root/.ssh 目录或者目录中的文件权限不对
二、安装 LAIN 客户端
开发 LAIN 应用时，需要安装 LAIN 客户端。LAIN 客户端依赖于： - docker - python
只要支持 docker 和 python 的系统，就可以使用 LAIN 客户端，比如 Linux 和 macOS。
以下均假设 LAIN 集群的 domain 为 lain.local，对于其他 domain，将下文中的 lain.local 替换即可。
1、安装与配置 docker
1）安装
请参考 安装 docker >= 1.12。
2）配置
Insecure Registries
安装好之后，请参考 将 registry.lain.local 添加进 docker daemon 的 insecure-registries 选项。
例如，在 Linux 上，如下的 /etc/docker/daemon.json 表示将 registry.lain.local 加入了 insecure-registries：
{ "insecure-registries" : ["registry.lain.local"]}
macOS 上的 insecure registries 配置如下图所示：
配置 insecure-registries 是因为 LAIN 集群的镜像仓库只提供了 HTTP 服务，没有提供 HTTPS 服务。
2、安装与配置 lain-cli
pip install lain-cli
推荐使用 virtualenv 安装这个 python 包，即：
pip install virtualenv # 安装 virtualenvvirtualenv lain # lain 是虚拟环境的名字，也可以取其他名字source lain/bin/activate # 激活 lain 虚拟环境pip install lain-clideactivate # 退出 lain 虚拟环境
以后需要使用 lain-cli 的时候，用 source ${lain-virtualenv-path}/bin/activate 激活 lain 虚拟环境； 不使用 lain-cli 的时候，用 deactivate 退出 lain 虚拟环境
安装好之后，需要配置 lain-cli，让 lain-cli 知道 LAIN 集群的 Domain 等信息：
lain config show # 显示当前配置lain config save-global private_docker_registry registry.lain.local # 配置 docker 私有仓库lain config save local domain lain.local # 保存 lain.local 集群，并取名为 local
假如 LAIN 集群开启了 sso 验证（默认未开启），请配置 sso：
lain config save local sso_url
3、配置 LAIN 组件的域名解析
如果 LAIN 集群不能在公网上解析（比如本地启动的集群），请配置 /etc/hosts。
如果启动集群时，使用了 vip 模式，即使用了 /vagrant/bootstrap -r docker.io/laincloud --vip=192.168.77.201启动，请执行：
echo "192.168.77.201 registry.lain.local console.lain.local entry.lain.local lvault.lain.local ipaddr-client.lain.local ipaddr-service.lain.local ipaddr-client.ipaddr-resource.resource.lain.local" >> /etc/hosts
192.168.77.201 是启动集群时的 vip 参数
如果启动集群时，没有使用 vip 模式，即使用了 /vagrant/bootstrap -r docker.io/laincloud 启动，请执行：
echo "192.168.77.21 registry.lain.local console.lain.local entry.lain.local lvault.lain.local ipaddr-client.lain.local ipaddr-service.lain.local ipaddr-client.ipaddr-resource.resource.lain.local" >> /etc/hosts
192.168.77.21 是集群的主节点的 IP，即启动集群的节点的 IP。
三、第一个 LAIN 应用
本节会演示如何基于 LAIN 集群创建一个 LAIN 应用，它提供 HTTP 服务，当用户访问 / 时，返回 Hello, LAIN.。
1、前置条件
首先需要一个 LAIN 集群，建议由 2 个节点组成其次需要本地的开发环境。具体步骤见安装 LAIN 客户端。LAIN 是基于 docker 的 PaaS 系统，建议先了解下 docker 的基本概念： - Docker 官方文档： - Docker 从入门到实践：
2、业务代码
package mainimport ( "net/http")func main() { http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) { w.Write([]byte("Hello, LAIN.")) }) http.ListenAndServe(":8080", nil)}
代码的逻辑为：
监听 0.0.0.0:8080 端口收到 /的 HTTP 请求时，返回 Hello, LAIN.3、lain.yaml
lain.yaml 是 LAIN 应用的配置文件，如下例所示：
appname: hello-world # 应用名，在集群内唯一，由小写字母、数字和 `-` 组成，且开头不能为数字，不能有连续的 `-`build: # 描述如何构建 hello-world:build-${git-committer-date}-${git-commit-hash} 镜像 base: golang:1.8 # 基础镜像，类似于 Dockerfile 里的 FROM script: - go build -o hello-world # 编译指令，类似于 Dockerfile 里的 RUN，WORKDIR 为 /lain/appproc.web: # 定义一个 proc，名字为 web type: web # proc 类型为 web（LAIN 会为 web 类型的 proc 配置 ${appname}.${LAIN-domain} 的域名，对外提供 HTTP 服务） cmd: /lain/app/hello-world # 因为 WORKDIR 为 /lain/app，所以编译好的程序在 /lain/app 目录下 port: 8080 # hello-world 监听的端口
因为我们需要提供 HTTP 服务，所以定义一个 web 类型的 proc，LAIN 集群会为 web 类型的 proc 自动分配 ${appname}.${LAIN-domain} 的域名。
proc.type 为 web 时，其名字也必须为 web，即一个 app 只能有一个 web 类型的 proc，且其名字为 web。
laincloud/hello-world@basic 的完整代码在这里：
4、本地运行
[vagrant@lain ~]$ cd ${hello-world-project} # 进入工程目录[vagrant@lain hello-world]$ lain build # 构建 hello-world:build-${git-committer-date}-${git-commit-hash} 镜像，生成编译结果>>> Building meta and release images ...>>> found shared prepare image at remote and local, sync ...>>> generating dockerfile to /Users/bibaijin/Projects/go/src/github.com/laincloud/hello-world/Dockerfile>>> building image hello-world:build-1496631978-a46ef7afcbbc18c1c1248bcbb84fa770d0758005 ...Sending build context to Docker daemon 6.656 kBStep 1/4 : FROM registry.lain.local/hello-world:prepare-0-1494908044 ---> 7406706a7f21Step 2/4 : COPY . /lain/app/ ---> 45f6215362adRemoving intermediate container 41e822d3b086Step 3/4 : WORKDIR /lain/app/ ---> 75c0f3094b6eRemoving intermediate container 24065cf1d7deStep 4/4 : RUN ( go build -o hello-world ) ---> Running in 43cefd489608 ---> 644f596f83c8Removing intermediate container 43cefd489608Successfully built 644f596f83c8>>> build succeeded: hello-world:build-1496631978-a46ef7afcbbc18c1c1248bcbb84fa770d0758005>>> tag hello-world:build-1496631978-a46ef7afcbbc18c1c1248bcbb84fa770d0758005 as hello-world:release-1496631978-a46ef7afcbbc18c1c1248bcbb84fa770d0758005>>> generating dockerfile to /Users/bibaijin/Projects/go/src/github.com/laincloud/hello-world/Dockerfile>>> building image hello-world:meta-1496631978-a46ef7afcbbc18c1c1248bcbb84fa770d0758005 ...Sending build context to Docker daemon 6.656 kBStep 1/2 : FROM scratch --->Step 2/2 : COPY lain.yaml /lain.yaml ---> cfdb9c518f0dRemoving intermediate container ab94a3603b8aSuccessfully built cfdb9c518f0d>>> build succeeded: hello-world:meta-1496631978-a46ef7afcbbc18c1c1248bcbb84fa770d0758005>>> Done lain build.[vagrant@lain hello-world]$ lain run web # 在本地运行>>> run proc hello-world.web.web with image hello-world:release-1496631978-a46ef7afcbbc18c1c1248bcbb84fa770d075800559f7fe4b1a7c6214361ecd5e06b19023ab7e02058888aa625749028af7b92954>>> container name: hello-world.web.web>>> port mapping:>>> 8080/tcp -> 0.0.0.0:32769lain-cli 的所有命令均需要在包含 lain.yaml 文件的目录下运行。lain-cli 依赖于 git 管理版本，所以要先安装 git，而且在 lain build之前进行 git commit
docker ps 时，可以看到：
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES59f7fe4b1a7c hello-world:release-1496631978-a46ef7afcbbc18c1c1248bcbb84fa770d0758005 "/lain/app/hello-w..." 27 seconds ago Up 31 seconds 0.0.0.0:32769->8080/tcp hello-world.web.web
上面的输出表示 lain 通过 docker 把 hello-world.web.web 容器里的 8080 端口映射到了主机的 32769，所以，可以在主机上访问：
[vagrant@lain hello-world]$ curl :32769Hello, LAIN.
得到了预期的结果。
5、部署到 LAIN 集群
从上一小节可以看到，本地运行没有问题，现在可以部署到 LAIN 集群了：
[vagrant@lain ~]$ cd ${hello-world-project} # 进入工程目录[vagrant@lain hello-world]$ lain build # 构建 hello-world:build-${git-committer-date}-${git-commit-hash} 镜像，生成编译结果[vagrant@lain hello-world]$ lain tag local # 类似于 docker tag，为 hello-world:(meta/release)-${git-committer-date}-${git-commit-hash} 镜像添加仓库前缀>>> Taging meta and relese image ...>>> tag hello-world:meta-1496631978-a46ef7afcbbc18c1c1248bcbb84fa770d0758005 as registry.lain.local/hello-world:meta-1496631978-a46ef7afcbbc18c1c1248bcbb84fa770d0758005>>> tag hello-world:release-1496631978-a46ef7afcbbc18c1c1248bcbb84fa770d0758005 as registry.lain.local/hello-world:release-1496631978-a46ef7afcbbc18c1c1248bcbb84fa770d0758005>>> Done lain tag.[vagrant@lain hello-world]$ lain push local # 类似于 docker push，将镜像推送到 LAIN 集群>>> Pushing meta and release images ...>>> pushing image registry.lain.local/hello-world:meta-1496631978-a46ef7afcbbc18c1c1248bcbb84fa770d0758005 ...The push refers to a repository [registry.lain.local/hello-world]1a4886bd9611: Layer already existsmeta-1496631978-a46ef7afcbbc18c1c1248bcbb84fa770d0758005: digest: sha256:daed70190af5fa980d6963fd3a6350591708c1568e180fe85e7eb6cfdd12d998 size: 524>>> pushing image registry.lain.local/hello-world:release-1496631978-a46ef7afcbbc18c1c1248bcbb84fa770d0758005 ...The push refers to a repository [registry.lain.local/hello-world]1a2245680fe1: Layer already existsdfe083dd50ba: Layer already existsedac683c8e67: Layer already exists0372f18510d4: Layer already existsc0b53d6ac422: Layer already existsbcf20a0a17f3: Layer already exists9d039e60afe3: Layer already existsa172d29265f3: Layer already existse6562eb04a92: Layer already exists596280599f68: Layer already exists5d6cbe0dbcf9: Layer already existsrelease-1496631978-a46ef7afcbbc18c1c1248bcbb84fa770d0758005: digest: sha256:1cea69b6ed882fcc16f1f5661b3830a8b3f20263264c51d0610b8ec09e72a439 size: 2626>>> Done lain push.[vagrant@lain hello-world]$ lain deploy local # 将应用部署到 LAIN 集群>>> Begin deploy app hello-world to local ...upgrading... Done.>>> app hello-world deploy operation:>>> last version: 1496631978-a46ef7afcbbc18c1c1248bcbb84fa770d0758005>>> this version: 1496631978-a46ef7afcbbc18c1c1248bcbb84fa770d0758005>>> if shit happened, rollback your app by:>>> lain deploy -v 1496631978-a46ef7afcbbc18c1c1248bcbb84fa770d0758005local 为 LAIN 集群的名字，请参考安装 LAIN 客户端中的设置lain tag 为镜像添加仓库前缀，之后才能进行 lain pushrelease 镜像包含了编译成果，将来会以这个镜像为基础运行容器meta 镜像包含 lain.yaml 文件，用于 LAIN 集群解析，用户不需要关心部署的过程是一个异步的过程，在 lain deploy local 之后可以使用 lain ps local 查询部署结果。
此时，可以通过以下命令访问 hello-world：
[vagrant@lain hello-world]$ curl -H "Host: hello-world.lain.local" , LAIN.
或者可以先更改 /etc/hosts 文件，然后直接使用域名访问：
[vagrant@lain hello-world]$ echo "192.168.77.201 hello-world.lain.local" >> /etc/hosts[vagrant@lain hello-world]$ curl , LAIN.
上面的 192.168.77.201 是本地 LAIN 集群的虚拟 IP，没有以 vip方式启动，请使用 192.168.77.21
得到了 Hello, LAIN. 的响应，符合我们的预期。
GitHub地址：
白皮书：
Ordinals铭文最全指南：看完这篇，认知将超过99%的人
一、比特币背景比特币采用了一个类似于现金的交易模型（cash system），其支付方式基于一种称为UTXO的模型，这与传统的基于账户余额的模型有所不同。举例而言：在银行的账户记账模型流程中，当A向B转账100元时，银行会记录三个步骤，这三个步骤构成了一个交易过程。第一步是从A的账户中扣除100元，这个步骤的记录ID为tid1。第二步是将100元存入B的账户中，这个步骤的记录ID为tid2。第三步是记录一笔转账记录，该记录将tid1和tid2关联起来，表示A账户减少100元，B账户增加100元。这样，A和B之间的转账关系就被记录下来，并且可以在未来查询与追踪。现在，我们将通过对于UTXO和支付模型的介绍，讲解比特币的支付方式。
UTXO在比特币区块链中，所有的余额都是存储在一个名为“未花费交易输出”（Unspent Transaction Output, UTXO）的列表中。每个UTXO都包含一定数量的比特币，以及这些比特币的所有者信息，并标明是否可用。可以将其想象成一张署有持有人姓名的现金支票，只要持有人在上面签名，就可以将使用权转让给他人。对于特定的地址，其所有的UTXO金额加起来即为该地址钱包的余额。通过遍历所有的UTXO，我们可以获取每个地址的当前余额。将所有的UTXO金额加总，则为当前全部流通的比特币。
在比特币的交易结构中，每笔交易都包括若干个输入和输出，其中每个输入是对一个已有的UTXO的引用，而每个输出则指定了新的资金接收地址及相应的金额。一旦一笔交易被发起，其输入部分所引用的UTXO便会被暂时锁定，以防止在交易完成前被重复使用。只有当这笔交易成功地被矿工打包到一个区块(Block)并获得网络确认后，相关的UTXO状态才会发生变化。具体来说，用于交易输入的UTXO将从UTXO列表中移除，表示它们已经被消费，而交易的输出则会生成新的UTXO，并添加到UTXO列表中。可以理解为，旧的现金支票被使用后失效，产生了新的现金支票，其所有权属于新的持有人。
值得强调的是，每个UTXO只能在一笔交易中被使用一次。一旦它作为输入被消费，它就会永久地从UTXO列表中移除。同时，新生成的输出作为新的UTXO加入到列表中。UTXO列表是不断变化的，随着每个新区块的创建，它会相应地进行更新。并且，通过分析区块链中的交易历史，我们能够重建在任何给定时间点的UTXO列表状态。
此外，一笔交易的总输入金额通常会略微超过其总输出金额。这个差额，称为交易费用(Transaction fee)或网络费(Network fee)，是作为激励给予负责将交易打包到区块的矿工的。网络费的大小与交易的复杂性成正比，因此，一笔包含更多输入和输出的交易通常需要支付更高的网络费。
现在，为了更加形象地理解比特币的交易结构，我们将通过一个具体的示例进行深入分析。比特币的交易结构如下，其中vin和vout这两个变量分别代表着比特币交易的 “输入” 与 “输出”。比特币的交易并不像传统的账户余额模型记录账户形的数据变化，而是通过输入和输出来表示。
const std::vector
我们可以在blockchain.com随机选一个交易记录来分析，下图展示了Hash ID为0627052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2的交易。其包含了一个输入和两个输出。
通过使用 bitcoin-cli 的命令getrawtransaction和decoderawtransaction，我们可以查看上述交易的底层结构：
{ "version": 1, "locktime": 0, "vin": [ { "txid": "7957a35fe64f80d234d76d83a2a8f1a0d8149a41d81de548f0a65a8a999f6f18", "vout": 0, "scriptSig" : "3045022100884d142d86652a3f47ba4746ec719bbfbd040a570b1deccbb6498c75c4ae24cb02204b9f039ff08df09cbe9f6addac960298cad530a863ea8f53982c09db8f6e3813[ALL] 0484ecc0d46f1918b30928fa0e4ed99f16a0fb4fde0735e7ade8416ab9fe423cc5412336376789d172787ec3457eee41c04f4938de5cc17b4a10fa336a8d752adf", "sequence": 4294967295 } ], "vout": [ { "value": 0.01500000, "scriptPubKey": "OP_DUP OP_HASH160 ab68025513c3dbd2f7b92a94e0581f5d50f654e7 OP_EQUALVERIFY OP_CHECKSIG" }, { "value": 0.08450000, "scriptPubKey": "OP_DUP OP_HASH160 7f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a8 OP_EQUALVERIFY OP_CHECKSIG", } ] }
在比特币网络中，交易输出包含两个重要信息：地址（公钥哈希）和 金额（以比特币为单位）。如果一个交易的输出没有在其他交易的输入中使用，那么这个交易输出就被称为未消费交易输出（UTXO）。谁拥有 UTXO 中公钥对应的私钥，谁就有权使用（即花费）这个 UTXO。
我们观察一下上面代码中的“vin”中的信息，它表示这个交易所花费的 UTXO 来自于另外一个交易（其 id 为7957a35fe64f80d234d76d83a2a8f1a0d8149a41d81de548f0a65a8a999f6f18）的第 0 个输出（一个交易的输出可以有多个，索引从 0 开始编号），我们可以从历史交易中查找出这个 UTXO 的金额（比如为 0.1），所以这个交易中这个用户花费了 0.1 BTC，数值 0.1 不需要显式地写在 交易中，而是通过查找 UTXO 信息来得到的。这个交易的“vout”有两个输出，这两个输出为两个新的UTXO，对应了新的余额以及持有人，直到有另外的交易把它们作为输入消费掉。
支付模型为了更好地理解比特币网络的支付模型，我们通过一个例子介绍由A支付给B金额为n的比特币的支付流程。下图展示了用户A发送3个比特币给用户B的过程。
对于用户A，首先需要确定其拥有的所有UTXO集合，即用户A可以支配的所有比特币；A从这个集合中选取一个或者多个UTXO作为交易的输入，这些输入的金额之和为m(2+0.8+0.5=3.3 BTC)要大于需要支付的金额n(3 BTC)；用户A为交易设置两个输出，一个输出支付给B的地址，金额是n(3 BTC)，另一个输出支付给A自己的一个找零地址，金额为m-n-fee(3.3-3-0.001=0.299 BTC)。用户的钱包通常由多个地址组成，一般情况下每个地址只使用一次，找零默认返回给一个新的地址；等矿工将这笔交易打包上链进行确认后，B就可以收到这笔交易信息。因为区块的大小有上限（约1 MB），所以矿工会优先确认交易费率(fee_rate=fee/size)高的交易，以获取最高的手续费回报。我们可以在mempool看到实时的挖矿 transaction fee 的情况。如果我们在转账过程中如果想要最快进行确认，就可以选择高优先权(High Priority)或者自定义(custom)一个合适的交易费率； 二、聪的编号与追踪比特币总量是2100万个，每个比特币包含10^8个聪(Satoshi, Sat)。因此，比特币网络上一共有2100万*10^8个聪。Ordinals协议将这些聪区分出来，为每个聪进行唯一编号。本节将介绍这个协议是如何做到为每一个聪进行唯一编号，并且如何追踪其所在的账户。此外，还会简介对于聪的稀有度份分类。
聪的编号根据 Ordinals 协议，聪的编号是根据它们被开采的顺序而定。下图展示了第0个区块挖出的第0个聪的表示方式。
对于聪的表达方式有多种：
整数符号：例如2099994106992659，表示该聪按照挖掘顺序所分配的序号。十进制符号：例如3891094.16797，第一个数字表示挖掘该聪的区块高度，第二个数字表示聪在区块中的编号。度数符号：例如3°111094′214″16797?，第一个数字是周期，从0开始编号，第二个数字是减半纪元的区块索引，第三个数字是难度调整期间的区块索引，最后一个数字是区块中sat的索引。百分比符号：例如99.99971949060254%，表示该聪在比特币供应量中的位置，以百分比表示。名称：例如Satoshi。使用字符a到z对序号进行编码的名称。我们将通过一个例子来讲解如何对新挖出的比特币进行编号。观察比特币区块链的第 795952 个区块，我们可以看到其中第一笔交易Tx 3a1f...b177记录了矿工的奖励（coinbase transaction）。这笔交易包含了新挖出的比特币，这些比特币是作为矿工的打包奖励，以及交易发起者付给矿工的手续费。通过查看下图的输入，我们可以发现其UTXO的id由一串0和区块高度组成。输出的地址则是矿工的钱包地址，金额则是上述的奖励和手续费的总和。
若我们进一步查看输出给矿工的部分，可以看到地址、金额以及所包含的聪的分布情况。如前所述，这些包含了挖矿奖励和手续费。其中，绿色的 sats 编号信息1941220000000000–1941220625000000是挖矿奖励产生的新聪，其余的 712 条聪的记录则对应了该区块中的所有手续费。
我们可以验证一下Sat 1941220000000000这个编号。它的block编号为795952，十进制符号(decimal)为795952.0，意味着挖掘该聪的区块高度为795952，聪在此区块中的编号为0，后面的稀有度(rarity)标记为uncommon，我们将在后面的部分进行详细介绍。
聪的流转因为每个BTC都是通过挖矿奖励产生的，所以他们都是可溯源的。比特币账户使用UTXO模型。假设用户A通过挖矿获得了第100-110个聪（10个聪是一个整体存放在同一个id为adc123的UTXO中）。当用户A要支付给用户B 5个聪时，他选择使用id为abc123作为交易的输入，其中5个聪给到用户B，5个聪作为找零返回给用户A。这两份5个聪都是一个整体，分别存放在两个id为abc456和abc789的UTXO中。上述UTXO id和聪的数量仅作为例子展示，在实际情况下发送的聪的数量最小限制为546个以及UTXO id也并非以此形式表达。
在上述的交易中，用户A的10个聪的流转路径为：
挖矿产生10个聪，编号是[100 *, 110)。*其表示编号为第100到第109个聪存放在id为abc123的UTXO中，其所有者为用户A。在A进行转账时，10个聪分成两份，每份5个聪。这里采用“先进先出”的原则，即聪的编号排序是按照它们在交易输出中的索引决定的。假设输出的顺序先是用户A，然后是用户B，那么用户A剩余5个聪的序号是[100, 105)，存放在id为abc456的UTXO中，而用户B的5个聪的序号是[105, 110)，存放在id为abc789的UTXO中。 稀有度（Rare Satoshi）作为Ordinals协议的衍生玩法，聪的稀有度可以根据它们的挖掘顺序来定义。这将导致一些特殊的聪具有不同的稀有度。以下是不同聪的稀有程度：
common普通级: 除区块第一个聪外的任何聪（总供应量为2100万亿）uncommon优良级: 每个区块的第一个聪（总供应量为6929999）rare稀有级: 每个难度调整期的第一个聪（总供应量为3437）epic史诗级: 每次减半后的第一个聪（总供应量为32）legendary传奇级：每个周期的第一个聪（总供应量为5）mythic神话级: 创世区块的第一个聪（总供应量为1）这种稀有聪的概念可以为比特币生态增加更多的趣味性和价值。不同稀有度的聪可能在市场上具有不同的价值，吸引收藏家和投资者。
三、铭文方式Ordinals与其他非比特币链上的NFT显著不同。其中，最主要的差异在于，Ordinals的元数据并没有存储在一个特定的位置上。相反，这些元数据被嵌入到交易的见证数据(witness data, witness field)中，这就是为何我们称之为 "铭文(inscription)" 的原因，因为这些数据被像铭文一样“刻”在比特币交易的特定部分上，而这些数据正是附着在特定聪上的。这一铭文过程通过隔离见证(Segregated Witness, SegWit)和“向Taproot支付”(Pay-to-Taproot, P2TR)的方式实现，其中包含了提交（commit）和揭露（reveal）两个阶段，能够将任何形式的内容（如文本、图像或视频）铭刻在指定的聪上。我们将在下文介绍另一种更加直接的存储方式OP_RETURN并阐述其为何没被作为铭文的手段。同时，我们会介绍隔离见证与Pay-to-Taproot是什么，以及他们在铭文中扮演什么角色。最后我们会介绍铭文的方式。
OP_RETURE在 Bitcoin Core 客户端 0.9 版中，通过采用 RETURN 操作符最终实现了妥协。**RETURN 允许开发者在交易输出上增加 80 字节的非支付数据。**与伪支付不同，RETURN 创造了一种明确的可验证不可消费型输出，此类数据无需存储于 UTXO 集。RETURN 输出被记录在区块链上，它们会消耗磁盘空间，也会导致区块链规模的增加，但它们不存储在 UTXO 集中，因此也不会使得 UTXO 内存池膨胀，更不会增加全节点昂贵的内存代价。
虽然OP_RETURN是一个非常直接的用以存储信息至比特币区块链的手段，它也是一个潜在的铭文方式。但是OP_RETURN的限制使得其在处理元数据存储时面临一些挑战。首先，OP_RETURN只能存储80字节的数据，对于需要存储更大量数据的情况来说，这种限制显然是无法满足的。其次，OP_RETURN数据被存储在交易输出部分，虽然这种数据不存储在UTXO集中，但是它们占用了区块链的存储空间，导致区块链规模的增加。最后，使用OP_RETURN会导致交易费用的提高，因为它需要支付更多的费用来发布这些交易。
隔离见证相比之下，SegWit提供的新方法则可以克服上述问题。SegWit是比特币的一个重要协议升级，由比特币核心开发者 Pieter Wuille 在 2015 年提出，最终在 2017 年的 0.16.0 版本中被正式采纳。Segregated Witness中的Segregated是分离、隔离的意思，Witness是与交易相关的签名事物。因此，SegWit是将某些交易签名数据(见证数据)与交易分开。
将签名与交易相关数据分离的主要好处是减少了存储在一个比特币块中的数据的大小。这样每个块具有额外的容量来存储更多的交易，也意味着网络可以处理更多的交易，并且发送者支付更低的手续费。从技术上来说就是把脚本签名(scriptSig)信息从基本结构 (base block) 里拿出来，放在一个新的数据结构当中。做验证工作的节点和矿工也会验证这个新的数据结构里的脚本签名，以确保交易有效。Segwit 升级在交易输出中引入了一个新的见证字段，以确保隐私和性能。虽然见证数据不是为了数据存储而设计的，但它实际上给了我们一个存储铭文元数据等内容的机会。我们通过下图来更加形象地理解隔离见证：
TaprootP2TR是比特币的一种交易输出类型，它是在2021年进行的Taproot升级中引入的，它使得不同的交易条件可以更加隐私地存储在区块链中。在Ordinals的铭文中，P2TR 扮演着至关重要的角色。铭文本质上是将特定的数据内容嵌入到比特币交易中，而Taproot升级，尤其是P2TR，使得这种嵌入数据变得更加灵活和经济。
首先，由于Taproot脚本的存储方式，我们可以在Taproot脚本路径支出脚本中存储铭文内容，这些脚本在内容方面几乎没有任何限制，同时还能获得见证数据的折扣，使得存储铭文内容相对经济。由于Taproot脚本的消费只能从已经存在的Taproot输出中进行，因此，铭文采用了两阶段的提交/揭示流程。首先，在提交交易中，创建了一个承诺包含铭文内容的脚本的Taproot输出。然后，在揭示交易中，消费了由提交交易创建的输出，从而在链上揭示了铭文内容。
这种做法大大降低了对资源的消耗。如果不使用P2TR，见证信息会存储在交易的输出中。这样，只要这笔输出未被消费，见证信息就会一直存储在UTXO集中。相反，如果使用了P2TR，见证信息不会出现在提交阶段生成的交易中，因此它不会被写入UTXO集。只有当这笔UTXO被消费时，见证信息才会在揭示阶段的交易输入中出现。P2TR让元数据能够写入比特币区块链，但却从未出现在UTXO集中。由于维护/修改UTXO集需要更多的资源，因此这种做法可以节省大量资源。
铭文Ordinals 协议利用了SegWit 放宽了对写入比特币网络内容的大小限制，将铭文内容存储在见证数据中。使其可以存储最大4MB的元数据。Taproot 使得在比特币交易中存储任意见证数据变得更加容易，允许 Ordinals 开发人员 Casey Rodarmor 将旧操作码（OP_FALSE、OP_IF、OP_PUSH）重新用于他所描述的「信封」为被称为「铭文」存储任意数据。
铸造铭文的流程包含以下两个步骤：
首先，需要在提交交易中创建一个承诺到包含铭文内容的脚本的Taproot输出。存储的格式是Taproot，即前一笔交易的输出是P2TR (Pay-To-Taproot)，后一笔交易的输入，在见证的Taproot script中嵌入特定格式的内容；首先将字符串ord入栈，以消除铭文有其他用途的歧义。OP_PUSH 1指示下一次推送包含内容类型，并OP_PUSH 0指示后续数据推送包含内容本身。大型铭文必须使用多次数据推送，因为 taproot 的少数限制之一是单个数据推送不得大于 520 字节。此时铭文的数据已对应到交易输出的UTXO上，但是未被公开。其次，需要在揭示交易中消费提交交易创建的那个输出。在这个阶段，通过将那笔铭文对应的UTXO作为输入，发起交易。此时，其对应的铭文内容被公开至全网。通过上述两个步骤，铭文内容已与被铭刻的UTXO进行绑定。再根据上文介绍的对于聪的定位，铭刻是在其输入的UTXO对应的第一个聪上进行，铭文内容包含在显示交易的输入中。根据上文介绍的对于聪的流转、跟踪的介绍，这个被铭刻上特殊内容的聪可以被转移、购买、出售、丢失和恢复。需要注意的是，不可以重复铭刻，否则后面的铭文是无效的。
我们将通过铭刻一个BTC NFT小图片的例子来详细说明这个过程，这个过程主要包括之前提到的提交（commit）和揭露（reveal）两个阶段。首先，我们看到第一笔交易的Hash ID是2ddf9...f585c。可以注意到，这笔交易的输出不包含见证数据，网页中也没有相关的铭文信息。
接着，我们查看第二阶段的记录，其Hash ID是e7454...7c0e1。在这里，我们可以看到Ordinals inscription 的信息，也就是见证的铭文内容。这笔交易的输入地址是前一个交易的输出地址，而输出的0.00000546BTC（546聪）则是将这个NFT发送到自己的地址。同时，我们也可以在Sat 1893640468329373中找到这个铭文所在的聪。
在比特币钱包中，我们可以看到这个资产。如果我们想要交易这个NFT，可以直接将其发送给其他人的地址，也就是将这笔UTXO发送出去，这样就完成了铭文的流转。
四、 比特币钱包在我们了解了什么是 Ordinals 生态、聪的流转以及铭文的相关知识后，目前有许多应用场景，无论是 BRC-20，ORC-20，BRC-721，GBRC-721等相关衍生协议的出现，需要我们有对应的钱包来支持和显示出代币信息或者 NFT 小图片。本节我们会介绍一下不同比特币钱包地址的概念和特点。
比特币地址以 1、3 或 bc1 开头。就像电子邮件地址一样，它们可以与其他比特币用户共享，这些用户可以使用它们将比特币直接发送到自己的钱包。从安全角度来看，比特币地址没有任何敏感内容。它可以在任何地方发布，而不会危及帐户的安全。与电子邮件地址不同，我们可以根据需要随时创建新地址，所有这些地址都会将资金直接存入您的钱包。事实上，许多现代钱包会自动为每笔交易创建一个新地址，以最大限度地保护隐私。钱包只是地址和解锁其中资金的钥匙的集合。首先我们要知道比特币钱包的地址是怎么产生的。
比特币私钥和公钥比特币采用椭圆曲线Secp256k1，“私钥”是1到n?1之间的随机数，n是个很大的数（256 个比特位），n 用科学计数法表示约为：
这个范围是极大的，我们是几乎无法猜出其他人的私钥的。这个随机整数私钥可以用 256 比特位表示，存在多种编码方式。如果使用WIF、WIF-compressed 形式的私钥是没有加密的，可以解码得到原始的那个“随机整数”。另一种方式是BIP38，提议用 AES 算法对私钥进行加密，这种方案得到的私钥以字符 6P 开头，这种私钥必须输入密码才能导入到各种比特币钱包中，这就是我们平时常用的私钥。
随后我们会利用椭圆曲线公式 K = kG，由私钥 k 来生成比特币的公钥 K，G为 Base Point，它是 secp256k1 的一个参数。可以得到 K 的两个坐标，就是公钥的两种表达方式，分别为“Uncompressed format”和“Compressed format”。
Uncompressed 形式，就是把两个坐标 x 和 y 直接连接在一起，再在前面加个 0x04 前缀即可；Compressed 形式，就是当 y 为偶数时，编码为 02 x，当 y 为奇数时，编码为 03 x； 比特币地址比特币各种类型的地址如下图可示，共有四种表示方法：
Reference:
1. Legacy (P2PKH)格式
范例：1Fh7ajXabJBpZPZw8bjD3QU4CuQ3pRty9u
地址以“1”开头，是比特币最初的地址格式，至今仍在使用。由公钥通过 Hash 计算后得到，也被称为P2PKH 是 Pay To PubKey Hash（付款至公钥哈希）的缩写。
2. Nested SegWit (P2SH)格式
范例：3KF9nXowQ4asSGxRRzeiTpDjMuwM2nypAN
地址以"3"开头，P2SH 是Pay To Script Hash（支付至脚本哈希）的缩写，它支持比Legacy 地址更复杂的功能。Nested P2SH，获取现有的P2SH地址(以“3”开头)，并与SegWit地址一起封装。
3. Native SegWit (Bech32)格式
范例：bc1qf3uwcxaz779nxedw0wry89v9cjh9w2xylnmqc3
在BIP0173中提出了 bc1 开头的地址，它们是原生的隔离见证地址。Bech32编码的地址，是专为SegWit开发的地址格式。Bech32在2017年底在BIP173被定义，该格式的主要特点之一是它不区分大小写（地址中只包含0-9，az），因此在输入时可有效避免混淆且更加易读。由于地址中需要的字符更少，地址使用Base32编码而不是传统的Base58，计算更方便、高效。数据可以更紧密地存储在二维码中。Bech32提供更高的安全性，更好地优化校验和错误检测代码，将出现无效地址的机会降到最低。
Bech32地址本身与SegWit兼容。不需要额外的空间来将SegWit地址放入P2SH地址，因此使用Bech32格式地址，手续费会更低。Bech32地址比旧的Base58（Base58Check编码用于将比特币中的字节数组编码为人类可编码的字符串）地址有几个优点：QR码更小；更好地防错；更加安全；不区分大小写；只由小写字母组成，所以在阅读、输入和理解时更容易。
4. Taproot格式(P2TR)
Bech32 有个缺点：如果地址的最后一个字符是 p，则在紧接着 p 之前的位置插入或者删除任意数量的字符 q 都不会使其 checksum 失效。
为了缓解 Bech32 的上述缺点，在BIP0350中提出了 Bech32m 地址：
对于版本为 0 的原生隔离见证地址，使用以前的 Bech32；对于版本为 1（或者更高）的原生隔离见证地址，则使用新的 Bech32m。对于 Bech32m 地址，当版本为 1 时，它们总是以bc1p开头（即 Taproot 地址）。具体来说，就像本地隔离见证一样，钱包可以由种子短语和密码短语组成。这些用于生成扩展的公钥和私钥，用于在分层确定性钱包中派生任意路径的地址。主要是储存BRC-20以及BTC的NFT等。
